\chapter{Project Planning}

% * (5 pages) Discuss how the planning and time management process worked
% * How closely did you keep to the plan, and in what ways did it change?

% Agile development process intro
Having all drawn from the good and bad experiences that we all during the
second year group project, we agreed very soon after forming our group that we
would have regular group meetings and set ourselves deadlines to help us to
remain on target throughout the duration of the project. As well as this,
regular meetings would help us all to be clear on what was expected of us for the
coming week, provide an opportunity to raise any issues that had become apparent
and suggest ideas that we might have. It was important for us that everyone
would be able to voice their opinion easily and that decisions would always be
made together as a group.

We didn't feel that it was necessary at this stage to assign any kind of ranking
in the group, in particular to have a project leader. This was based on our
previous experiences of working together; we knew that we were all motivated and
had clear ideas of what was expected of us. We also believed it was important that
everyone had input into every aspect of the design and features of the game.

Since none of us had worked on a project like this before, we were all
unfamiliar with the elements involved. We did not know what software we would be
using, we were not confident with the C++ and had little idea on the content
and functionality for our game. Due to this, it was not appropriate to construct a
complex or complete plan. We decided against adopting a traditional iterative
system such as the waterfall model and instead opted for a more agile
strategy to the project. We wanted to continually work through the processes of
planning, design, implementation and testing throughout the project in order to
keep development as adaptive as possible to any changes. We endeavoured to do
this by setting frequent and short-term deadlines based on a rougher larger
scale plan. When we could make more solid judgements we could update our plan
and targets to encompass them. We had all had experience with agile development
earlier in the year with the Advanced Software Development unit, and we were
keen to work using the model again.

\section{Our Initial Planning}

% agile development process, working closely as a team with regular
% communication in meetings meant that this would work

We were all aware from the beginning of the year that three out of the five in
our group were taking five units in the first term and three in the second, with
the other two team members having an equal split of four and four. After we had
found out the decision of which game we were to undertake, we were all very
eager to make progress with it. However, the first term of the third year took
us all by surprise. The amount of coursework we had, coupled with the fact that
three of us were more busy with five units meant that we were not able to really
start any serious work on the game until after Christmas.

The work that we did manage to get done in the first term, was mainly research
into all the various possibilities of engines and libraries that we believed may
be of use to us. We also took time to speak to the previous groups about their
experiences with working with the pod, and in particular technical issues
associated with controlling the pod.

Once we had decided on the details of which engines and libraries we were using,
we wanted to tie down the details of the game as much as we could into a
specification document. This was an important step for us because many of the
details were not fully decided, or known only to one person. Producing a
specification meant that we would all have a good understanding of the
composition of the project and could see it as a whole more clearly.

From the specification we produced, as best we could at the time, a set of tasks
that would be required to complete the project. For each task we made estimates
of how long it would take us, and worked out the other tasks that it would
depend on and that should be completed first. We used this information to create
a dependency diagram to help us plan out the order in which things should be
done. With all of this information in mind, we created a set of targets that
would give work towards a basic alpha release by the beginning of the Easter
holidays. All of these documents that we had produced were shared between us
using Google Documents, this meant that they were easily available to us at all
times (with a web-browser) and that if anyone made any updates or changes, they
would be recorded as a revision and reflected in everyones copies.

At the very beginning of development, several of the initial tasks had many
inter-dependencies; for example, we had to work together in order to link up
user input to the physics engine. Since it was likely that these would not all
be undertaken by the same person, it was critical that they were all completed
and hence that we had a basic working version before Easter when we all went our
own separate ways during the holidays. Then it wasn't necessary, but still
useful, that we were all around at exactly the same times during the holidays.
However, we could still make clear progress during this time by working on different,
non-dependent tasks that didn't require as much cooperation until the holidays
had finished.

Whenever we were planning on working to a deadline, we tried to assign tasks to
each member of the group so that everyone was absolutely sure of what they
needed to do. When deciding who would be responsible for which sections of our
game, we considered that some of us were busier than others and that some of us
had preference to some sections. We tried to match tasks so that no one was
responsible for a critical task when they didn't have time to complete it whilst
also trying to ensure that everyone was doing something that they enjoyed. We
all decided to share evenly the more mundane tasks such as sending out emails
with meeting minutes.

\section{Meetings}

We decided from the very beginning that we would have weekly meetings to discuss
our progress during the previous week. We also agreed that we were all expected
to be present at each meeting to ensure that we were all working consistently
and as everyone's input to discussions was vital to any decisions that had to be
made. Unfortunately, as was mentioned in the previous section, this did not
occur as planned. Before Christmas our weekly meetings only happened once a
month due to the fact that we were making such little progress and consequently
we did not have much to discuss. We made the decision for this to happen, as it
was just not beneficial to meet every week. As the term ended, with the prospect
of a lot of time to work on the project over Christmas, we agreed that we should
start the meetings again properly. From this point on, due to the lighter work
load for us in the second term we were all able to put a lot more work into the
project, which made the meetings vastly more productive.

% what we talked about in meetings
At each meeting we would always try to achieve several important tasks. Firstly,
it was important to discuss what we had each been working on since the last
meeting. This was so that everyone was aware of how things were progressing and
also so that we could see how it matched up with the progress that we planned to
make. Once we had analysed our small, shorter term targets, we could look at how
they affected the progression towards the main deadlines. Secondly, we would
talk about the features and functionality of the game, both those that we were
working on and ideas for possible changes or enhancements. Many of the ideas
that we had for the game were not fully formed, but as we were completing other
features, they needed to be finalised so that we could implement them. Meetings were
also a good time for us to discuss technical problems that we may be having.
Often, other people's opinions and views were valuable in solving an issue.
Thirdly, we would decide what would be accomplished individually and as a group
by the next time we would meet and possibly adjust the plan to compensate for this.

% after a meeting
After each meeting, we sent the minutes to everyone in an email and also copied
them into a shared Google document. This meant that they were immediately
available for any necessary adjustments to be made. This also meant that if
anyone was unable to attend a meeting they could catch up on what had happened and
add their own comments if necessary.

\section{Targets and Interim Deadlines}

% why we had deadlines
Interim deadlines were incredibly important to the success of our project.
Although we were all keen and motivated about working on the game, having such a
large time-frame on the project meant that it was difficult to continuously work
hard with the final hand-in as such a distant target. We all agreed that we
worked best under pressure, so having these deadlines would provid a solid
target to work towards. After we had written our specification and broken the
project down into smaller manageable tasks, we set ourselves three main interim
deadlines at which we would have a version of the code that would be able
to demo some core functionality of the game. For example, the first release
required basic integrated graphics and physics engine functionality and
networked motion pod control.

% and targets for each deadline
The main deadlines that we set ourselves were intended not to be very flexible.
This was because there were very few of them and they were placed such that they
could not easily be moved and could be met on time. Reasons for this included the
Systems Integration coursework deadline and our various absences over the Easter
holidays. For the planning and development to remain agile though, we ensured
that we kept our smaller shorter term targets flexible. This allowed us to be
able to easily incorporate new ideas into the game or change existing ones, such
as refactoring the structure of classes in our code or to add a new dynamic
element of the gameplay.

% timechart to visualise it
To help us visualise how we were doing and the time-frames involved, we created a
chart which mapped out the remaining weeks to the final deadline. Marked on this
was all of our own planned targets and deadlines. We used this in conjunction
with our meetings to discuss the next week's work and help plan out future
deadlines.

\section[Plan Adaptation]{Adaptation of the Plan to Fit Changing Requirements}

% our agile planning & development
As mentioned in the preceding sections, none of us had any prior experience with
making computer games. Due to this, inevitably our ideas relating to to all
aspects of the game from its theme to complex technical details changed rapidly
as time progressed. This was something that we expected to happen so we planned
for it as best we could. We found though that there were two vital ingredients
that made the agile development strategy work. The first of these was good,
frequent communication as a group. This ensured that everyone had an active role
in discussions and decision making, and that this process could occur quickly.
We spent a significant part of the project working together which naturally
achieved this. The second ingredient was flexible but consistent and solid
planning. Although we were aware that things were always changing, our short
term targets and longer term deadlines were always in place as milestones to
provide motivation to work towards.

% New ideas
There were a number of factors that affected the success and progression of our
planning, these factors motivated us to maintain flexible development throughout
the project. The most significant of these was the constant stream of ideas that
everyone had for the game. Our initial description of the game that we
formulated for the pitch provided a broad overview, but did not have specific
details. This was sufficient to get started but meant that we needed to decide
as we went, details such as what pick-ups would be available. Our regular
meetings provided the best opportunity to discuss and decide on such details.
The second most significant factor contributing to changes in our plan was
unforseen problems. This might mean that something may take twice as long as
anticipated, or even that it is not at all possible to continue with it. Early
on in the development, we made two big changes to the libraries we were using;
we switched from using the ODE physics library to Newton and from using an
XML-RPC network protocol to using our own one implemented with Sockets.

% unforseen problems
As with any project there is always the threat of unforseen problems to strike
at any point. Preparation for such issues is difficult and usually involves
allowing contingency time. We experienced several unforseen problems, which meant
that we had to modify our current plans for the project. The main problem was
the pod's joystick. We spent a great deal of time trying to compensate
for the poor quality of its output values, but in the end had to give up because
with it our game was unplayable. This meant that having already spent a
significant amount of time tweaking the way we used the pod joystick, we had to
spend even more time adapting our input system to use a USB joystick.

% refactoring
One of the benefits of working in an agile sense and not iteratively is that it
meant we could refactor our code when we saw that it was necessary. This
happened a few times, the first was with the network code. We made the decision
to change the communication protocol from using ASCII strings to be binary
instead. At the time there was no desperate need to change it, but we felt that
it would be beneficial for the communication overhead to be optimised as we were
sure the game would only demand faster communication with the pod server.
Another significant refactoring was performed on the input system code. We
redesigned it from a single piece of a code to encompass each input device into
several seperate objects. Doing this incurred a period of no functional progress but
was paid off with the work performed after as it made our code more logical and
easier to write and made the incorporation of other inputs, such as replays,
far simpler.

% actually changing the plan
After one of these issues had affected the game, for example when we had decided to add
a new feature or encountered a serious problem with some code, as well as from
dealing with the issue, we needed to amend our plan. In this respect we never
deviated from our plan because we would always adjust it to reflect new
decisions. However, there is then the risk that with such a relaxed
attitude to changes like this, the plan may not be as feasible as it once was.
As a group we were always open to new ideas for game features or to reorganise
or refactor existing work, but we remained aware of the constraints of time upon
us. Our discussions as a group and deadlines we had set enabled us to consider
each idea carefully.

\section{Testing}

% agile/iterative testing

We were keen to incorporate testing heavily into the development of the game,
right from the very beginning. This was so we could find and resolve as many of
the problems and bugs in the game as we could while we were writing code,
instead of doing it all right at the end whilst altering the game throughout the
development to incorporate any feedback we got. We did not set up a formal
testing framework because of the nature of the software which means that the
testing inherently requires human input. Instead, we regularly invited friends
and collegues, who represent the target audience for the game well, to come and
play it. We observed how they played and what went wrong. They also
provided us with their invaluable comments and criticisms. A good example of
this was when several people commented that it would be great to include
power-ups for the orb in the levels.

% final testing
Although we spent time iteratively testing the game we wanted to have an intense
period of play testing before the deadline with the game in a very-nearly
finished state. Initially we planned to have the game in a position to do this
two weeks before the final deadline, however it became apparent that testing in
the penultimate week would be best as we were quite confident from the
previous testing perfomed and it would give us just the right amount of time to
get the last key features finished. This final stage of testing served mainly to
identfiy any bugs within the game. Although we received many suggestions for
improvements, we had to focus our time to amend the smaller bug-related issues.
There were several points though where we took note from people's comments at
this stage. One of these issues concerned the background music. We did not demo
the game to the testers with any music but asked them whether or not they felt
it was necessary for the game. We received a mixed response but on the whole
people's responses were along the lines of "Yes, background music would be good,
but only if it fits in well with the gameplay". This response prompted us to
incorporate some music that we had found, but until that point had not been
sure about.

% a last concluding paragraph?
